5.3.3 APPX Application Design Manual

+ Chapter 1-1: Overview of Application Design
+ Chapter 1-2: Getting Started
+ Chapter 1-3: Data Dictionary
+ Chapter 1-4: Understanding Process Design
+ Chapter 1-5: Interprocess Communication
+ Chapter 1-6: Customizing Your Application
+ Chapter 1-7: The Documentation Facility
+ Chapter 1-8: Application Design Tools
+ Chapter 2-1: Data Dictionary Overview
+ Chapter 2-2: Data Dictionary Concepts
+ Chapter 2-3: Domains
+ Chapter 2-4: Files and Fields
+ Chapter 2-5: Work Fields
+ Chapter 3-1: Overview of APPX Processes
+ Chapter 3-2: Getting Started
+ Chapter 3-3: Process Definition
+ Chapter 3-4: Menu Processes
+ Chapter 3-5: Job Processes
+ Chapter 3-6: Input Processes
+ Chapter 3-7: Output Processes
+ Chapter 3-8: Update Processes
+ Chapter 3-9: Query Processes
+ Chapter 3-10: Inquiry Processes
+ Chapter 3-11: Status Processes
+ Chapter 3-12: Subroutine Processes
+ Chapter 3-13: Table Processes
+ Chapter 3-14: Automatic and Optional Children
+ Chapter 3-15: Using the Image Editor
+ Chapter 3-16: Using GUI Features of the Image Editor
+ Chapter 3-17: Using Event Points
+ Chapter 4-1: ILF Integration
+ Chapter 4-2: True/False Status Indicators
- Chapter 4-3: Specifying Statements
+ Chapter 4-4: The ILF Editor
+ Chapter 4-5: The Appx ILF Debugger
+ Chapter 4-6: ILF Keyword Reference
+ Chapter 4-7: Predefined Fields
+ Chapter 4-8: Runtime Subroutine's and Predefined Processes
+ Chapter 4-9: Appx Chart Director API

Chapter 4-3: Specifying Statements

A Non-APPX Program Name


There are two ILF statements that can invoke a non-APPX program name. Use RUN to execute complete external programs. Use CALL to call external subroutines. Most operating systems support dynamic link libraries. If the subroutine you wish to call is part of a dynamic link library, you can invoke it directly in APPX by using the CALL statement. If a subroutine must be statically linked, you will have to create a custom APPX engine in order to invoke it. Contact your system administrator for details regarding this procedure.

When you invoke external programs and subroutines with the RUN and CALL statements, you specify the exact program name that you would enter if you were communicating directly with the native operating system on a command line. If you do not have enough spaces to specify the name completely, you can define a work field in the data dictionary and set its value to the complete program name. In turn, specify the work field name in the RUN or CALL statement to achieve the desired effect.

Another reason to consider using a work field definition is ease of maintenance. You may RUN or CALL the same program or routine in several places in your application environment. If for any reason you need to change the name of a program and had specified it directly in a RUN or CALL statement, you must change each statement where the name is specified. If you define a work field in the data dictionary, you only have one change to make if the program name changes.

Application Design Manual                                         "Powered by Appx Software"

552

©2006 By APPX Software, Inc. All Rights Reserved